Description

• Change search term format from keyword arg to namedtuple of (<attribute>, <operator>, <value>)
• Define SearchTerm namedtuple
• Modify search page, views, and tests to use new format

Closes #61

Motivation and Context

SearchTerm Format

A three-term format provides more flexibility than a keyword arg. For example, we'd run into trouble using keyword args if we wanted to support both exact match and fuzzy match on entry titles, but with the tuple format we can apply different operators to the same attribute / value pairs.

Using a namedtuple for the format provides the option of setting and accessing args by name without taking more memory than bare tuples.

Operators

I included the operators:

• eq (equals)
• lt (less than or equal to)
• gt (greater than or equal to)
• in (item in container)
• like (partial match)
• isclose (number within absolute and relative tolerances)

lt and gt are both inclusive because I felt that that was more intuitive, and that we didn't need to also support exclusive versions. like currently supports regex string and UUID matches.

isclose takes an arg with format (<value>, <rel_tolerance>, <abs_tolerance>). The client converts this SearchTerm to lt and gt; the intention is that tolerances can be taken from the user or from the Entry directly, which the client turns into upper and lower bounds.

entry_type requires special handling because type comparisons need subclass information.

Tags

FilestoreBackend implicitly supports tags using the gt operator, but a dedicated operator may be required when other backends are added. To find entries whose tag set contains all tags in a filter, use the conditional ('tags', 'gt', {<tags>...}), which calls set.__ge__. Supporting more complex tag filters, like inversion or disjunction, will also require a tag operator or using Flag functionality.

How Has This Been Tested?

Existing tests in test_page, test_window, and test_backend.
New tests for lt, gt, fuzzy match, and tag filters.

Where Has This Been Documented?

This PR

Pre-merge checklist

• Code works interactively
• Code follows the style guide
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate